Field
Embodiments generally relate to deployment and merge of independent application and/or software releases for a product line.
Related Art
Large systems (e.g., medical systems like medical imaging devices and hospital management systems) include multiple products from different origins (e.g., business units with specific applications). These products are developed independently but use common product-line code, for example, for common look and feel, run-time infrastructures, data repositories, and domain specific protocols and tech-stacks.
On the one hand, the products are intended to be independent of each other, have internal product variability, extensibility, deployments on multiple physical or virtual machines, and dedicated shipment time points from their development sites, where the products have been developed independent from other development sites. On the other hand, applications from these independent products have considerable technical dependencies among each other, due to large amount of common product-line code that sits in such an application, and because applications from two independent products often need tighter technical coupling for specialized medical diagnostics (e.g., MR+MI, CT+MI), or at least need a joint deployment on the same hardware box and software run-time system, due to, for example, cost constraints.
Without additional technical solutions and under the above constraints, a system installation and deployment may fail or render an unusable system, no matter if the medical system is installed from scratch with contributions from multiple independent products or if there is one independent application release added to an existing installation, due to the many touch points of that additional product with the existing system.
The reasons for potential failures are technical conflicts. The main conflict is that imperative (must have) overrides (files, data, content) on the existing system by an independent product releases may not be allowed, but can't be avoided with current technology, yet replacements may be business critical. Even worse, the installers (e.g., Window Installer) do not support smart merges and may give up control over the installation of a product if this installation received imperative overrides.
Examples of known deployment solutions are described below.
In one known solution, all independent products with their variability options are finally decided and synchronized before shipment, and all variability is ‘frozen’ initially, and ‘unfrozen’ after installation is complete. So all constraints are resolved at development time in a ‘combined’ release of independent products centrally on one dedicated ‘integration’ site for all contributing sites. Shipping goes to one or more physical machine or box with actually identical ‘frozen’ setup. But this combined delivery solution does not allow product release independence, for example, neither independent release time-points nor independent shipment of release content from, for example, only one site.
In another known solution, merges based on pure ‘eternal’ backward or forward compatibility have failed. For example, Microsoft had promised the backward compatibility of the Win32 API for many years, but finally gave up. Microsoft had also promised .NET framework compatibility but failed. Windows Updater avoids any merge, but imperatively replaces local files after a difference query with the installed releases and downloads from the deployment store. Native software distribution mechanisms (e.g., based on a Managed Node Package, Microsoft Active Directory, etc.) ship software packages but assume that all further decisions are taken by some other software on the target node.
In another known solution, the same product can be installed in many versions, the user or the application picks the right version by manual selection or by always using the own installation path, never relate neither products nor multiple versions of the same product to each other, but keep them independent, use isolated install subdirectory trees for each product and product version and always separated installation packages. This is the default solution used by all vendors, like Microsoft. Visual Studio application and .NET frameworks, Java Run-Time, Perl programming language, Adobe Reader application, and many more. Some software force the user to first install the correct version of their underlying run-time system, for example, the required version of the Java run-time, regardless of potential side-effects on other Java based software on the same machine. Some software even refuse to exist more than once on a machine and force the user to remove previous versions of the same product, like Microsoft Windows or releases of SAP's enterprise software.
Each of the above known solutions does not allow for release independence of applications or software.